I presume 1.4 in your case means 1.4 seconds to run the query that's causing the hyperevent error? Not always but sometimes I find hyperevent errors in synchronous processes having some sort of infinite loop somewhere in the code.

In the past to determine which part of csp is causing an issue I've used ^%SYS.MONLBL which is mainly used to log the amount of time each line in a routine (mac/int) takes to execute but since csp gets compiled to .cls and .cls gets compiled to .int you can add the .int part of the csp to monitor the csp. 

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...

In the early stages async web sockets definitely had many issues. I had many similar issues when trying the ..ShareConnection=1 in 2015.1.2 and as you mentioned, synced web sockets worked fine. I contacted WRC and they advised me to upgrade to 2017.1.2. Upgrading to 2017.1.2 fixed all the issues I had, so not sure what the exact problem you have is but upgrading might be the only solution. 

If possible it's always recommended to use the  Caché  implemented predicates rather than the ANSI sql ones as they will normally always be faster. Execute the same queries in the management portal on large tables and you can verify those for yourself.

The list of those are here:  Caché  https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=RSQL_PREDICATE_CONDITONS
 

To answer your question via timed tests:

Query 1 (Iterating 100 million times...) :

Example 1 :

w $ZTS F i=1:1:100000000 {S a="345",b="arun",c="kumar",d="hi",e="yello",f="orange"} w !,$ZTS                                                              
64708,68916.71
64708,68926.342
~9.632 secs

Example 2

w $ZTS F i=1:1:100000000 {S a="345" s b="arun" s c="kumar" s d="hi" s e="yello" s f="orange"} w !,$ZTS                                                    
64708,68900.72
64708,68910.376 
~ 9.656 secs

Query 2 (Iterating 1 billion times!!!): 

Example 1:

w $ZTS F i=1:1:1000000000 {S:a=1 R="Arun"} w !,$ZTS                       
64708,69223.394
64708,69246.773
~ 23.379 secs

Example 2:

w $ZTS F i=1:1:1000000000 {I a=2 S R="Arun"} w !,$ZTS
64708,69264.946
64708,69289.174
~ 24.228 secs 

@  Vitaliy Serdtsev (100 million iterations)

w $ZTS F i=1:1:100000000 {s (a,b,c)=0} w !,$ZTS
64708,69571.214
64708,69577.797
~6.583 secs
w !,$ZTS F i=1:1:100000000 {s a=0,b=0,c=0} w !,$ZTS
64708,69589.118
64708,69595.433
~6.315 secs
w !,$ZTS F i=1:1:100000000 {s a=0 s b=0 s c=0} w !,$ZTS
64708,69793.562
64708,69799.545
~ 5.983

As everyone said, setting variables/ conditional statements is probably not where it's getting slow. As someone mentioned PERFMON is a great tool . Another one is ^%SYS.MONLBL. 

I just got too much bloody time .... 

Hi,

Your question is a bit confusing. Neither of those are valid HL7 messages. Do you mean that first $$$LOGINFO("Stream: " pInput.GetData(1)) is generating the first example message? In the first message you seem to only be getting back the first 8 characters from each line. Are there any limitations in the number of characters defined somewhere? 

The second one is due to the Schema being a default Ensemble one. From your message it seems like you will need to define a custom schema type according to your HL7 specification. 

Kind regards,

Alice

A quick note from the documentation:

"%SelectMode

The LIKE predicate does not use the current %SelectMode setting. A pattern should be specified in Logical format, regardless of the %SelectMode setting. Attempting to specify a pattern in ODBC format or Display format commonly results in no data matches or unintended data matches.

You can use the %EXTERNAL or %ODBCOUT format-transform functions to transform the scalar-expression field that the predicate operates upon. This allows you to specify the pattern in Display format or ODBC format. However, using a format-transform function prevents the use of the index for the field, and can thus have a significant performance impact."

I'm not sure if this affects you but can you try:

SELECT lnkdid,
c_fastsearch_code,
c_drugfull
FROM JAC.drug_basic
WHERE %ODBCOUT(c_drugfull) LIKE 'Para%'

If none of those above solutions work, it might be possible to use emergency login into the system. Then setup your own username and password in the management portal once in. 

1. Stop cache instance. 

2. Open windows cmd as "Run as administrator".

3. Browse to the bin directory inside the directory where you installed cache.

4. use the command 

ccontrol start <instance> /EmergencyId=<username>,<password>

Where instance is the name of your Caché instance, and type any username and password.

E.g: 

ccontrol start MyCache /EmergencyId=Eugenia,52601

Try to login using that and then setup a username and password and then restart Caché to login via the newly setup username and password. You can read more under "Emergency Access" here:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

If the second FTP server is in your local network, is it possible to map the drive to a local drive? Once you do this, in theory you should be able to directly download the file to the mapped drive without relying on ftp to download and then upload. 

If this process still writes the file to CACHE.dat then I would simply create a batch file in windows that can download the file into the mapped drive or local drive and upload if necessary, then run the batch file, either using windows task manager or task scheduler in Ensemble (RunLegacyTask) and use Do $ZF(-1,(batch file location)) or Do ##class(%Net.Remote.Utility).RunCommandViaZF((batch file location),,.rt). 

If the growing CACHE.Dat file is an issue then you can use Compacting and Truncating feature described here:  http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...