{"action":"created","issue":{"url":"https://api.github.com/repos/CORE-POS/IS4C/issues/442","labels_url":"https://api.github.com/repos/CORE-POS/IS4C/issues/442/labels{/name}","comments_url":"https://api.github.com/repos/CORE-POS/IS4C/issues/442/comments","events_url":"https://api.github.com/repos/CORE-POS/IS4C/issues/442/events","html_url":"https://github.com/CORE-POS/IS4C/issues/442","id":56019911,"number":442,"title":"Agenda Idea for 2015-01-30 -- Toward a guideline for addressing Slowness","user":{"login":"flathat","id":1131922,"avatar_url":"https://avatars.githubusercontent.com/u/1131922?v=3","gravatar_id":"","url":"https://api.github.com/users/flathat","html_url":"https://github.com/flathat","followers_url":"https://api.github.com/users/flathat/followers","following_url":"https://api.github.com/users/flathat/following{/other_user}","gists_url":"https://api.github.com/users/flathat/gists{/gist_id}","starred_url":"https://api.github.com/users/flathat/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/flathat/subscriptions","organizations_url":"https://api.github.com/users/flathat/orgs","repos_url":"https://api.github.com/users/flathat/repos","events_url":"https://api.github.com/users/flathat/events{/privacy}","received_events_url":"https://api.github.com/users/flathat/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/CORE-POS/IS4C/labels/Agendas%20and%20Minutes","name":"Agendas and Minutes","color":"207de5"},{"url":"https://api.github.com/repos/CORE-POS/IS4C/labels/Code%20Enhancing","name":"Code Enhancing","color":"ededed"},{"url":"https://api.github.com/repos/CORE-POS/IS4C/labels/Documentation","name":"Documentation","color":"ededed"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-01-30T10:56:16Z","updated_at":"2015-01-30T17:05:50Z","closed_at":null,"body":"I'm again having to answer complaints about slowness.  In addition to dealing with my immediate issue in the first paragraph below I'd like to gather information for a guide on the subject, describing issues, and techniques that work and those that don't or aren't worth the trouble.  A pertinent bit of context is that the complaints are due in part to veteran cashiers being very familiar with the system now and not as patient as they once were; this is particularly the case for single-item transactions on busy days. The expectation is for desktop-application-like speed; the bar keeps rising.\r\n\r\n1. Delay opening cash drawer at the end of a transaction.  There is some good information about this in #245, which I didn't find until late in my current research.  Cashiers now describe delays of long enough to exchange a couple remarks with the customer before the drawer opens. The delays are not consistent during a day or from day to day.  Our Fannie is in the cloud, not on the LAN.  In `ajax-end.php`, which handles what happens after the tender modules are finished, the upload of the transaction to Fannie happens before the drawer kick.  Intermittent delay in connecting to the remote server may be part of the problem (to test this I want to run in offline mode for a while, by not calling `DisplayLib::testremote()` from `ajax-end.php::cleartemptrans()`).  There is code in `ajax-end` about dealing with the script hanging if there is a problem with the printer. #321 led to a solution (that I'm embarrassed to say I haven't installed yet).  My question now is whether, with the #321 solution, the drawer kick and receipt printing could be done before the upload without excessive risk, and let the upload happen in the lull between customers?\r\n\r\n2. Slow populating lists.  There are fewer complaints here, but since the operation is local a connection delay isn't likely the problem.  Product, `PV`, lookups are a string search over the description in the whole table.  I don't think intra-word strings are usually being searched so I wonder if its worth it to see if word-indexing the description will give faster results?  At one time I wondered if caching that table in memory might help, but [most of what I've read] (http://stackoverflow.com/questions/4343225/mysql-how-to-keep-entire-myisam-table-in-memory) about this says that the automatic OS caching is probably doing all that can be done, so not worth trying to improve it.\r\n\r\n3. Scanner/scale driver using 100% of CPU. In Linux, on an idle lane, `top` reports that mono, running the scanner/scale driver) is using 100% of CPU, apache2 30% and firefox 12%. On my desktop when CPU usage gets above 50% the slowdown is noticeable and at 100% very little happens.  So something else must be the case here because the POS response is snappy if not lightning under that load.  Would it be better still if the driver slept a bit, and s/s still respond quickly enough?  Could the driver be restricted to one core on a multi-core machine, or is that happening already and I'm just not reading or using top correctly to see it?\r\n\r\n4. Scanner/scale files in memory.  The (original IS4C scanner/scale installation docs) [http://www.wedge.coop/is4c/doc/scannerscale.html] describe creating a RAM disk for scanner/scale scan files.  Is there still an advantage to doing this?"},"comment":{"url":"https://api.github.com/repos/CORE-POS/IS4C/issues/comments/72234126","html_url":"https://github.com/CORE-POS/IS4C/issues/442#issuecomment-72234126","issue_url":"https://api.github.com/repos/CORE-POS/IS4C/issues/442","id":72234126,"user":{"login":"jdpurdyvi","id":196235,"avatar_url":"https://avatars.githubusercontent.com/u/196235?v=3","gravatar_id":"","url":"https://api.github.com/users/jdpurdyvi","html_url":"https://github.com/jdpurdyvi","followers_url":"https://api.github.com/users/jdpurdyvi/followers","following_url":"https://api.github.com/users/jdpurdyvi/following{/other_user}","gists_url":"https://api.github.com/users/jdpurdyvi/gists{/gist_id}","starred_url":"https://api.github.com/users/jdpurdyvi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jdpurdyvi/subscriptions","organizations_url":"https://api.github.com/users/jdpurdyvi/orgs","repos_url":"https://api.github.com/users/jdpurdyvi/repos","events_url":"https://api.github.com/users/jdpurdyvi/events{/privacy}","received_events_url":"https://api.github.com/users/jdpurdyvi/received_events","type":"User","site_admin":false},"created_at":"2015-01-30T17:05:50Z","updated_at":"2015-01-30T17:05:50Z","body":"2) Could you capture what some of these queries are?\r\n\r\n4) Probably not a huge difference. We were just excited about using a new idea at the time."}}